Update to Cryptography Research Skills
Snapshot Oct 28, 2026 · 12:44 UTC · version 0.2.0
Collection source: downloaded plugin package. These snapshots do not have a confirmed matching collection source. Differences in file lists alone do not establish changes to the package.
Instructions updated for cryptography-writing
Skill instructions — Now says: [ASD-STE100 Simplified Technical English](https://www.asd-ste100.org/STE_faq.html) as plain-language style guidance: prefer clear, focused sentences and...
Observed in instructions or declared skills. Runtime behavior has not been tested.
Up to 3 plugins free · no card required.
All fields and original values.
Skill instructions
Sep 30, 2026 · 23:17 UTC
the entrypoint alone for a straightforward edit with fixed meaning. Read the relevant reference when drafting substantial material or resolving an uncertainty: | Abstract or introduction structure | [Abstracts and introductions](referenc...
Oct 28, 2026 · 12:44 UTC
[ASD-STE100 Simplified Technical English](https://www.asd-ste100.org/STE_faq.html) as plain-language style guidance: prefer clear, focused sentences and active voice where appropriate. Judge clarity by continuity, emphasis, and grammatic...
Supporting files
Sep 30, 2026 · 23:17 UTC
[{"relative_path":"references/abstract-introduction-evidence.md","size_in_bytes":19691},{"relative_path":"references/abstracts-and-introductions.md","size_in_bytes":6132},{"relative_path":"references/conservative-editing.md","size_in_byt...
Oct 28, 2026 · 12:44 UTC
[{"relative_path":"references/abstract-introduction-evidence.md","size_in_bytes":19691},{"relative_path":"references/abstracts-and-introductions.md","size_in_bytes":8888},{"relative_path":"references/conservative-editing.md","size_in_byt...
Compare saved observations
Download comparison JSONSKILL.md text changes
− removed · + added
--- before +++ after @@ -7,8 +7,24 @@ Make the contribution and argument precise and readable. Use established terms when they express the intended formal meaning; otherwise name the object or relationship plainly. Theory-only writing needs no implementation or experiments. +Use [ASD-STE100 Simplified Technical English](https://www.asd-ste100.org/STE_faq.html) as plain-language style guidance: prefer clear, focused sentences and active voice where appropriate. Judge clarity by continuity, emphasis, and grammatical structure as well as length; a longer or passive sentence may keep the relationship clearer. Do not impose the standard's restricted vocabulary or dictionary-based word-use restrictions. Preserve mathematical precision, established cryptographic terminology, notation, and the author's explicit instructions. + +Prefer concrete cryptographic nouns and operations over generic labels such as “endpoints,” “layer,” “interface,” “publish,” or “pad.” Name the parties, OT roles, protocol phase, primitive, PRF outputs, messages, broadcast, or reconstruction actually meant. Prefer “corrupted parties” to “coalition” when describing the corrupted set, and name supplied correlations rather than calling them “scalar correlations” or “OT state.” Explain what is sampled or causes an abort instead of relying on “marginal” or “cutoff” alone. + +For drafting or terminology revision, use the wording defaults in [terminology](references/terminology.md). They express preferred prose, not claims that the avoided words are unknown in cryptography. Preserve exact mathematical distinctions, formal interfaces, complete retained state, source-defined terms, and technically meaningful uses such as “one-time pad.” Local author instructions can override these defaults. + +## State results directly + +State the strongest supported contribution directly. Remove apologies, repeated caveats, and imagined reviewer objections that add no information. Express limitations as precise scope conditions or tradeoffs, without turning a local negative result into a judgment on the whole construction. Keep qualifications that change the claim, including the corruption model, setup, leakage, abort guarantee, and unresolved proof obligations. Do not ban words mechanically: “only the output is revealed” can state an essential guarantee. + ## Work from the active claim +Check project guidance for the author's explicit wording corrections and +accepted replacements. Preserve their scope and later reverts. When an +existing term already names the intended object, prefer it to inventing and +defining another label; a terminology question alone does not authorize +manuscript edits. + 1. Resolve the requested source version and active text. Read the relevant definitions, notation, theorem, and nearby argument before changing a technical claim. 2. Identify what the sentence relies on: the experiment or functionality, adversary and corruption, setup and oracle access, quantifiers and bounds, assumptions, composition, leakage, and output guarantee. State the material conditions or point to a definition fixing them; do not repeat the whole model in every sentence. 3. Distinguish the intended target, the theorem stated, the reasoning supplied, and any implemented variant. Draft only what the available material supports; never invent a citation, proof step, assumption, or result. @@ -19,13 +35,15 @@ ## Load details only for the current task -Use the entrypoint alone for a straightforward edit with fixed meaning. Read the relevant reference when drafting substantial material or resolving an uncertainty: +Use the entrypoint alone for a straightforward grammar edit with fixed meaning. For drafting or terminology changes, use the terminology reference above; read other references only for the relevant task: | Task | Reference | | --- | --- | -| Abstract or introduction structure | [Abstracts and introductions](references/abstracts-and-introductions.md) | +| Abstract, introduction, or conclusion structure; consistency with a technical overview | [Abstracts, introductions, and conclusions](references/abstracts-and-introductions.md) | | Explain a construction or proof idea | [Technical overviews](references/technical-overviews.md) | -| Ambiguous cryptographic word or claim verb | [Terminology](references/terminology.md) | +| Sentence or paragraph coherence; substantial prose revision | [Prose and coherence](references/prose-and-coherence.md) | +| Exposition of definitions, notation, formulas, or lemmas | [Mathematical exposition](references/mathematical-exposition.md) | +| Preferred wording, an ambiguous cryptographic word, or a claim verb | [Terminology](references/terminology.md) | | Security statements, experiments, reductions, or full proofs | [Security claims](references/security-claims.md) | | MPC, simulation, corruption, composition, or output guarantees | [Secure computation](references/secure-computation.md) | | Proof systems, extraction, commitments, or oracle models | [Proof systems and oracles](references/proof-systems-and-oracles.md) |
Full technical diff · 2 changed fields
changed /included_files
[
{
"relative_path": "references/abstract-introduction-evidence.md",
"size_in_bytes": 19691
},
{
"relative_path": "references/abstracts-and-introductions.md",
"size_in_bytes": 6132
},
{
"relative_path": "references/conservative-editing.md",
"size_in_bytes": 3612
},
{
"relative_path": "references/constructions-and-costs.md",
"size_in_bytes": 8309
},
{
"relative_path": "references/proof-systems-and-oracles.md",
"size_in_bytes": 9493
},
{
"relative_path": "references/secure-computation.md",
"size_in_bytes": 13101
},
{
"relative_path": "references/security-claims.md",
"size_in_bytes": 6380
},
{
"relative_path": "references/technical-overview-evidence.md",
"size_in_bytes": 20671
},
{
"relative_path": "references/technical-overviews.md",
"size_in_bytes": 7193
},
{
"relative_path": "references/terminology.md",
"size_in_bytes": 3214
}
][
{
"relative_path": "references/abstract-introduction-evidence.md",
"size_in_bytes": 19691
},
{
"relative_path": "references/abstracts-and-introductions.md",
"size_in_bytes": 8888
},
{
"relative_path": "references/conservative-editing.md",
"size_in_bytes": 3612
},
{
"relative_path": "references/constructions-and-costs.md",
"size_in_bytes": 10222
},
{
"relative_path": "references/mathematical-exposition.md",
"size_in_bytes": 5004
},
{
"relative_path": "references/proof-systems-and-oracles.md",
"size_in_bytes": 9493
},
{
"relative_path": "references/prose-and-coherence.md",
"size_in_bytes": 4055
},
{
"relative_path": "references/secure-computation.md",
"size_in_bytes": 13106
},
{
"relative_path": "references/security-claims.md",
"size_in_bytes": 8697
},
{
"relative_path": "references/technical-overview-evidence.md",
"size_in_bytes": 23580
},
{
"relative_path": "references/technical-overviews.md",
"size_in_bytes": 8491
},
{
"relative_path": "references/terminology.md",
"size_in_bytes": 9820
}
]changed /skill_md_contents
"---\nname: cryptography-writing\ndescription: Draft or minimally edit cryptography manuscripts, including definitions, theorem statements, security arguments, abstracts, and technical overviews. Preserve the construction and guarantee; use crypto-proof-auditor for substantive proof-validity review.\n---\n\n# Cryptography Writing\n\nMake the contribution and argument precise and readable. Use established terms when they express the intended formal meaning; otherwise name the object or relationship plainly. Theory-only writing needs no implementation or experiments.\n\n## Work from the active claim\n\n1. Resolve the requested source version and active text. Read the relevant definitions, notation, theorem, and nearby argument before changing a technical claim.\n2. Identify what the sentence relies on: the experiment or functionality, adversary and corruption, setup and oracle access, quantifiers and bounds, assumptions, composition, leakage, and output guarantee. State the material conditions or point to a definition fixing them; do not repeat the whole model in every sentence.\n3. Distinguish the intended target, the theorem stated, the reasoning supplied, and any implemented variant. Draft only what the available material supports; never invent a citation, proof step, assumption, or result.\n4. Match the work to the request. Reviewing or suggesting wording does not authorize file edits. For authorized edits, preserve unrelated changes and make the smallest technically correct repair unless a rewrite is requested. Keep notation, macros, labels, comments, wrapping, and the author's voice.\n5. Check the resulting claim against its sources and inspect the diff. Follow applicable manuscript checks when editing source files. If a repair requires a new model, theorem, or authorial choice, report the ambiguity and a narrow alternative rather than silently changing it.\n\nLocal definitions take precedence over generic terminology. Keep correctness, security, and implementation evidence distinct; likewise joint distributions versus marginals, success probability versus advantage, concrete versus asymptotic bounds, and ideal-resource guarantees versus concrete instantiations. A stylistic edit cannot establish a missing theorem.\n\n## Load details only for the current task\n\nUse the entrypoint alone for a straightforward edit with fixed meaning. Read the relevant reference when drafting substantial material or resolving an uncertainty:\n\n| Task | Reference |\n| --- | --- |\n| Abstract or introduction structure | [Abstracts and introductions](references/abstracts-and-introductions.md) |\n| Explain a construction or proof idea | [Technical overviews](references/technical-overviews.md) |\n| Ambiguous cryptographic word or claim verb | [Terminology](references/terminology.md) |\n| Security statements, experiments, reductions, or full proofs | [Security claims](references/security-claims.md) |\n| MPC, simulation, corruption, composition, or output guarantees | [Secure computation](references/secure-computation.md) |\n| Proof systems, extraction, commitments, or oracle models | [Proof systems and oracles](references/proof-systems-and-oracles.md) |\n| Construction interfaces, preprocessing, rounds, or costs | [Constructions and costs](references/constructions-and-costs.md) |\n| Mixed edit authorization or multiple manuscript variants | [Conservative editing](references/conservative-editing.md) |\n\nThe narrative guides link optional source examples; those corpora are not required reading. Load multiple references only when the claim actually crosses their topics.\n\n## Full proof drafting\n\nFor a new simulation-based proof or an authorized substantial rewrite, a useful default is to describe the simulator's information, interfaces, state, and behavior, then justify meaningful real-to-ideal transitions and accumulate their bounds. Preserve the complete joint view and conditional distributions, including for perfect security. A direct equality-of-distributions argument can suffice; do not invent intermediate experiments or impose particular labels. Follow the governing definition and the author's organization when another presentation is clearer.\n\nA requested substantive validity audit or proof completion may need `crypto-proof-auditor`; source/PDF verification may need `crypto-manuscript-qa`. Use companions only for those additional tasks, not automatically during prose editing. Deliver the prose or minimal patch, with only material unresolved technical questions.\n"
"---\nname: cryptography-writing\ndescription: Draft or minimally edit cryptography manuscripts, including definitions, theorem statements, security arguments, abstracts, and technical overviews. Preserve the construction and guarantee; use crypto-proof-auditor for substantive proof-validity review.\n---\n\n# Cryptography Writing\n\nMake the contribution and argument precise and readable. Use established terms when they express the intended formal meaning; otherwise name the object or relationship plainly. Theory-only writing needs no implementation or experiments.\n\nUse [ASD-STE100 Simplified Technical English](https://www.asd-ste100.org/STE_faq.html) as plain-language style guidance: prefer clear, focused sentences and active voice where appropriate. Judge clarity by continuity, emphasis, and grammatical structure as well as length; a longer or passive sentence may keep the relationship clearer. Do not impose the standard's restricted vocabulary or dictionary-based word-use restrictions. Preserve mathematical precision, established cryptographic terminology, notation, and the author's explicit instructions.\n\nPrefer concrete cryptographic nouns and operations over generic labels such as “endpoints,” “layer,” “interface,” “publish,” or “pad.” Name the parties, OT roles, protocol phase, primitive, PRF outputs, messages, broadcast, or reconstruction actually meant. Prefer “corrupted parties” to “coalition” when describing the corrupted set, and name supplied correlations rather than calling them “scalar correlations” or “OT state.” Explain what is sampled or causes an abort instead of relying on “marginal” or “cutoff” alone.\n\nFor drafting or terminology revision, use the wording defaults in [terminology](references/terminology.md). They express preferred prose, not claims that the avoided words are unknown in cryptography. Preserve exact mathematical distinctions, formal interfaces, complete retained state, source-defined terms, and technically meaningful uses such as “one-time pad.” Local author instructions can override these defaults.\n\n## State results directly\n\nState the strongest supported contribution directly. Remove apologies, repeated caveats, and imagined reviewer objections that add no information. Express limitations as precise scope conditions or tradeoffs, without turning a local negative result into a judgment on the whole construction. Keep qualifications that change the claim, including the corruption model, setup, leakage, abort guarantee, and unresolved proof obligations. Do not ban words mechanically: “only the output is revealed” can state an essential guarantee.\n\n## Work from the active claim\n\nCheck project guidance for the author's explicit wording corrections and\naccepted replacements. Preserve their scope and later reverts. When an\nexisting term already names the intended object, prefer it to inventing and\ndefining another label; a terminology question alone does not authorize\nmanuscript edits.\n\n1. Resolve the requested source version and active text. Read the relevant definitions, notation, theorem, and nearby argument before changing a technical claim.\n2. Identify what the sentence relies on: the experiment or functionality, adversary and corruption, setup and oracle access, quantifiers and bounds, assumptions, composition, leakage, and output guarantee. State the material conditions or point to a definition fixing them; do not repeat the whole model in every sentence.\n3. Distinguish the intended target, the theorem stated, the reasoning supplied, and any implemented variant. Draft only what the available material supports; never invent a citation, proof step, assumption, or result.\n4. Match the work to the request. Reviewing or suggesting wording does not authorize file edits. For authorized edits, preserve unrelated changes and make the smallest technically correct repair unless a rewrite is requested. Keep notation, macros, labels, comments, wrapping, and the author's voice.\n5. Check the resulting claim against its sources and inspect the diff. Follow applicable manuscript checks when editing source files. If a repair requires a new model, theorem, or authorial choice, report the ambiguity and a narrow alternative rather than silently changing it.\n\nLocal definitions take precedence over generic terminology. Keep correctness, security, and implementation evidence distinct; likewise joint distributions versus marginals, success probability versus advantage, concrete versus asymptotic bounds, and ideal-resource guarantees versus concrete instantiations. A stylistic edit cannot establish a missing theorem.\n\n## Load details only for the current task\n\nUse the entrypoint alone for a straightforward grammar edit with fixed meaning. For drafting or terminology changes, use the terminology reference above; read other references only for the relevant task:\n\n| Task | Reference |\n| --- | --- |\n| Abstract, introduction, or conclusion structure; consistency with a technical overview | [Abstracts, introductions, and conclusions](references/abstracts-and-introductions.md) |\n| Explain a construction or proof idea | [Technical overviews](references/technical-overviews.md) |\n| Sentence or paragraph coherence; substantial prose revision | [Prose and coherence](references/prose-and-coherence.md) |\n| Exposition of definitions, notation, formulas, or lemmas | [Mathematical exposition](references/mathematical-exposition.md) |\n| Preferred wording, an ambiguous cryptographic word, or a claim verb | [Terminology](references/terminology.md) |\n| Security statements, experiments, reductions, or full proofs | [Security claims](references/security-claims.md) |\n| MPC, simulation, corruption, composition, or output guarantees | [Secure computation](references/secure-computation.md) |\n| Proof systems, extraction, commitments, or oracle models | [Proof systems and oracles](references/proof-systems-and-oracles.md) |\n| Construction interfaces, preprocessing, rounds, or costs | [Constructions and costs](references/constructions-and-costs.md) |\n| Mixed edit authorization or multiple manuscript variants | [Conservative editing](references/conservative-editing.md) |\n\nThe narrative guides link optional source examples; those corpora are not required reading. Load multiple references only when the claim actually crosses their topics.\n\n## Full proof drafting\n\nFor a new simulation-based proof or an authorized substantial rewrite, a useful default is to describe the simulator's information, interfaces, state, and behavior, then justify meaningful real-to-ideal transitions and accumulate their bounds. Preserve the complete joint view and conditional distributions, including for perfect security. A direct equality-of-distributions argument can suffice; do not invent intermediate experiments or impose particular labels. Follow the governing definition and the author's organization when another presentation is clearer.\n\nA requested substantive validity audit or proof completion may need `crypto-proof-auditor`; source/PDF verification may need `crypto-manuscript-qa`. Use companions only for those additional tasks, not automatically during prose editing. Deliver the prose or minimal patch, with only material unresolved technical questions.\n"
Full snapshot data
{
"description": "Draft or minimally edit cryptography manuscripts, including definitions, theorem statements, security arguments, abstracts, and technical overviews. Preserve the construction and guarantee; use crypto-proof-auditor for substantive proof-validity review.",
"included_files": [
{
"relative_path": "references/abstract-introduction-evidence.md",
"size_in_bytes": 19691
},
{
"relative_path": "references/abstracts-and-introductions.md",
"size_in_bytes": 8888
},
{
"relative_path": "references/conservative-editing.md",
"size_in_bytes": 3612
},
{
"relative_path": "references/constructions-and-costs.md",
"size_in_bytes": 10222
},
{
"relative_path": "references/mathematical-exposition.md",
"size_in_bytes": 5004
},
{
"relative_path": "references/proof-systems-and-oracles.md",
"size_in_bytes": 9493
},
{
"relative_path": "references/prose-and-coherence.md",
"size_in_bytes": 4055
},
{
"relative_path": "references/secure-computation.md",
"size_in_bytes": 13106
},
{
"relative_path": "references/security-claims.md",
"size_in_bytes": 8697
},
{
"relative_path": "references/technical-overview-evidence.md",
"size_in_bytes": 23580
},
{
"relative_path": "references/technical-overviews.md",
"size_in_bytes": 8491
},
{
"relative_path": "references/terminology.md",
"size_in_bytes": 9820
}
],
"name": "cryptography-writing",
"skill_md_contents": "---\nname: cryptography-writing\ndescription: Draft or minimally edit cryptography manuscripts, including definitions, theorem statements, security arguments, abstracts, and technical overviews. Preserve the construction and guarantee; use crypto-proof-auditor for substantive proof-validity review.\n---\n\n# Cryptography Writing\n\nMake the contribution and argument precise and readable. Use established terms when they express the intended formal meaning; otherwise name the object or relationship plainly. Theory-only writing needs no implementation or experiments.\n\nUse [ASD-STE100 Simplified Technical English](https://www.asd-ste100.org/STE_faq.html) as plain-language style guidance: prefer clear, focused sentences and active voice where appropriate. Judge clarity by continuity, emphasis, and grammatical structure as well as length; a longer or passive sentence may keep the relationship clearer. Do not impose the standard's restricted vocabulary or dictionary-based word-use restrictions. Preserve mathematical precision, established cryptographic terminology, notation, and the author's explicit instructions.\n\nPrefer concrete cryptographic nouns and operations over generic labels such as “endpoints,” “layer,” “interface,” “publish,” or “pad.” Name the parties, OT roles, protocol phase, primitive, PRF outputs, messages, broadcast, or reconstruction actually meant. Prefer “corrupted parties” to “coalition” when describing the corrupted set, and name supplied correlations rather than calling them “scalar correlations” or “OT state.” Explain what is sampled or causes an abort instead of relying on “marginal” or “cutoff” alone.\n\nFor drafting or terminology revision, use the wording defaults in [terminology](references/terminology.md). They express preferred prose, not claims that the avoided words are unknown in cryptography. Preserve exact mathematical distinctions, formal interfaces, complete retained state, source-defined terms, and technically meaningful uses such as “one-time pad.” Local author instructions can override these defaults.\n\n## State results directly\n\nState the strongest supported contribution directly. Remove apologies, repeated caveats, and imagined reviewer objections that add no information. Express limitations as precise scope conditions or tradeoffs, without turning a local negative result into a judgment on the whole construction. Keep qualifications that change the claim, including the corruption model, setup, leakage, abort guarantee, and unresolved proof obligations. Do not ban words mechanically: “only the output is revealed” can state an essential guarantee.\n\n## Work from the active claim\n\nCheck project guidance for the author's explicit wording corrections and\naccepted replacements. Preserve their scope and later reverts. When an\nexisting term already names the intended object, prefer it to inventing and\ndefining another label; a terminology question alone does not authorize\nmanuscript edits.\n\n1. Resolve the requested source version and active text. Read the relevant definitions, notation, theorem, and nearby argument before changing a technical claim.\n2. Identify what the sentence relies on: the experiment or functionality, adversary and corruption, setup and oracle access, quantifiers and bounds, assumptions, composition, leakage, and output guarantee. State the material conditions or point to a definition fixing them; do not repeat the whole model in every sentence.\n3. Distinguish the intended target, the theorem stated, the reasoning supplied, and any implemented variant. Draft only what the available material supports; never invent a citation, proof step, assumption, or result.\n4. Match the work to the request. Reviewing or suggesting wording does not authorize file edits. For authorized edits, preserve unrelated changes and make the smallest technically correct repair unless a rewrite is requested. Keep notation, macros, labels, comments, wrapping, and the author's voice.\n5. Check the resulting claim against its sources and inspect the diff. Follow applicable manuscript checks when editing source files. If a repair requires a new model, theorem, or authorial choice, report the ambiguity and a narrow alternative rather than silently changing it.\n\nLocal definitions take precedence over generic terminology. Keep correctness, security, and implementation evidence distinct; likewise joint distributions versus marginals, success probability versus advantage, concrete versus asymptotic bounds, and ideal-resource guarantees versus concrete instantiations. A stylistic edit cannot establish a missing theorem.\n\n## Load details only for the current task\n\nUse the entrypoint alone for a straightforward grammar edit with fixed meaning. For drafting or terminology changes, use the terminology reference above; read other references only for the relevant task:\n\n| Task | Reference |\n| --- | --- |\n| Abstract, introduction, or conclusion structure; consistency with a technical overview | [Abstracts, introductions, and conclusions](references/abstracts-and-introductions.md) |\n| Explain a construction or proof idea | [Technical overviews](references/technical-overviews.md) |\n| Sentence or paragraph coherence; substantial prose revision | [Prose and coherence](references/prose-and-coherence.md) |\n| Exposition of definitions, notation, formulas, or lemmas | [Mathematical exposition](references/mathematical-exposition.md) |\n| Preferred wording, an ambiguous cryptographic word, or a claim verb | [Terminology](references/terminology.md) |\n| Security statements, experiments, reductions, or full proofs | [Security claims](references/security-claims.md) |\n| MPC, simulation, corruption, composition, or output guarantees | [Secure computation](references/secure-computation.md) |\n| Proof systems, extraction, commitments, or oracle models | [Proof systems and oracles](references/proof-systems-and-oracles.md) |\n| Construction interfaces, preprocessing, rounds, or costs | [Constructions and costs](references/constructions-and-costs.md) |\n| Mixed edit authorization or multiple manuscript variants | [Conservative editing](references/conservative-editing.md) |\n\nThe narrative guides link optional source examples; those corpora are not required reading. Load multiple references only when the claim actually crosses their topics.\n\n## Full proof drafting\n\nFor a new simulation-based proof or an authorized substantial rewrite, a useful default is to describe the simulator's information, interfaces, state, and behavior, then justify meaningful real-to-ideal transitions and accumulate their bounds. Preserve the complete joint view and conditional distributions, including for perfect security. A direct equality-of-distributions argument can suffice; do not invent intermediate experiments or impose particular labels. Follow the governing definition and the author's organization when another presentation is clearer.\n\nA requested substantive validity audit or proof completion may need `crypto-proof-auditor`; source/PDF verification may need `crypto-manuscript-qa`. Use companions only for those additional tasks, not automatically during prose editing. Deliver the prose or minimal patch, with only material unresolved technical questions.\n"
}SHA-256 of public snapshot: d8b0865b19741b4d92f8710911fd9b045a2fed58342b6ec9d916208a66aaf200