Update to Cryptography Research Skills

{
  "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": 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
    }
  ],
  "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\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"
}